Groovypedia:Administrator
Administrators are registered users who have "sysop rights". Current Groovypedia policy is to appoint new admins when it is felt that the current number of admins is insufficient. Administrators are chosen from Groovypedia contributors who are active and who have been around for a while and are generally known and trusted members of the community. Administrators are not imbued with any special authority, and are equal to everybody else in terms of editorial responsibility. Some Wiki users consider the terms "Sysop" and "Administrator" to be misnomers, as they just indicate registered users who have had performance- and security-based restrictions on several features lifted because they seemed like trustworthy folks and asked nicely. However it should be noted that administrators do not have any special power over other users other than applying decisions made by all users. The community does look to administrators to perform essential housekeeping chores that require the extra access administrators are entrusted with. Among them are watching the Votes for deletion debates and carrying out the consensus of the community on keeping or deleting these articles, keeping an eye on new and changed articles to swiftly delete obvious vandalism, and meeting user requests for help that require administrative access. Since administrators are expected to be experienced members of the community, users seeking help will often turn to an administrator for advice and information. *Knightfall *Judgement *Thecircle *Blue Stav *OmNomNomAttack So, what's the deal? The Wiki software has a few important features that are restricted. Of those restricted features, administrators have access to the following. Protected pages *Directly edit protected pages. For information and guidelines, see Groovypedia:Editing protected pages. *Protect and unprotect pages. Pages are only protected in certain rare circumstances—for information and guidelines, see Groovypedia:Protection policy. Deletion and undeletion *Delete pages and their history. For information and guidelines, see both Groovypedia:deletion policy and (most definitely) Groovypedia:Deletion guidelines for administrators. To suggest a page to delete (after reading the policy and guidelines pages!), see Groovypedia:Votes for deletion. Sometimes deletion is a technical matter, in which a redirection page has to be removed to make way for renaming an article, or a page whose history has been broken up has to be deleted and the pieces recombined. Other times it's a matter of cleaning up simple junk edits on pages with no actual content, or removing material that has been pasted in from another site and infringes copyright. *View and restore deleted pages and their history. See Groovypedia:Undeletion for guidelines. To challenge an already made decision to delete a page, see Groovypedia:Votes for undeletion *Permanently delete images. This is a non-reversible change: once deleted, always deleted. For information and guidelines, see Groovypedia:Image use policy. To suggest an image to delete (after reading the policy), see Groovypedia:Images for deletion. To challenge a decision to delete an image, make sure that you still have a copy of the image (else there is no way to restore it), then see Groovypedia:Votes for undeletion. Note that there is no particular reason that image deletion should not be reversible; this is simply the way the software works at present. Reverting *Revert pages quickly. Any user (logged-in or not) can revert a page to an earlier version. Administrators have a faster, automated reversion tool to help them revert vandalism by anonymous editors. When looking at a user's contributions, a link that looks like: rollback – appears next to edits that are at the top of the edit history. Clicking on the link reverts to the last edit not authored by that user, with edit summary (Reverted edits by X to last version by Y) and marks it as a minor change. In a fairly recent change, admins can also rapidly revert changes when viewing a diff. Enforcement of Arbitration Committee rulings Admins have the authority to enforce rulings by the Arbitration Committee. See: Wikipedia:MediaWiki:Requests for arbitration/Admin enforcement requested Hiding vandalism from recent changes * Sysops can hide vandalism from . To do this, add &bot=1 to the end of the URL used to access a user's contributions. For example, http://www.that70sshow.wikicities.com/w/wiki.phtml?title=Special:Contributions&target=Eric&bot=1. When the rollback links on the contributions list are clicked, the revert and the original edit that you are reverting will both be hidden from the default Recentchanges display (by using the marker originally added to keep massive bot edits from flooding recentchanges, hence the "bot"). This means that they will be hidden from recent changes unless you click the "bots" link to set hidebots=0. The edits are not hidden from contributions lists, page histories or watchlists. The edits remain in the database and are not removed, but they no longer flood Recentchanges. The aim of this feature is to reduce the annoyance factor of a flood vandal with relatively little effort. This should not be used for reverting a change you just don't like, but is meant only for simple vandalism, particularly massive flood vandalism. Block and unblock * Block IP addresses, IP ranges, and user accounts, for a specific time, or indefinitely. * Unblock IP addresses, IP ranges, and user accounts. * See Groovypedia:blocking policy for more information on when blocks are appropriate and when they are not. See for currently blocked addresses and usernames Design and wording of the interface * As of December 6, 2003, sysops can change the text of the interface by editing the pages in the MediaWiki namespace. This includes the text at the top of pages such as the "Special:Whatlinkshere" and the page that a blocked user will see when they try to edit a page (MediaWiki:Blockedtext). * As of June 3, 2004, sysops can edit the style of the interface by changing the CSS in the monobook stylesheet at MediaWiki:Monobook.css. Becoming an administrator If you would like sysop access, and you are willing to take on a little more responsibility in the Groovypedia community, add your name to Groovypedia:Requests for adminship according to the guidelines mentioned there, and a voting will take place by fellow editors in order to determine if you should become an administrator. It's recommended that you write for Groovypedia for at least a month and a half (60 days) before requesting administrator status, since other users will have to recognize you before they can agree on your promotion. Be careful, please! If you are granted access, we ask that you exercise care in using these functions, especially the ability to delete pages and their history, to delete images (which is permanent!), and the ability to block IP addresses. You can learn about your newfound powers at the Administrator's how-to guide. You should also take a look at the pages linked from the Administrators' reading list before using any of your sysop abilities. Other access types In addition to administrators, there are other types of identified users, listed here in roughly ascending order of power. (Administrators, clearly, go after Signed-in users.) Signed-in users Users with ordinary access, including visitors who haven't "signed in," can still do most things, including the most important: editing articles and helping with Groovypedia maintenance tasks. But only signed-up users can or rename pages; see to sign up for yourself. Bureaucrats Users with "bureaucrat" status can turn other users into sysops (but not remove sysop status). Bureaucrats are created by other bureaucrats on projects where these exist, or by stewards on those who don't yet have one. Sysoppings are recorded in . Sysoppings by stewards are recorded at Meta:Special:Log/rights but the few stewards who actively sysop users on Groovypedia do so using their local bureaucrat status, making this distinction rather academic. Stewards Users with "steward" status can change the access of any user on any Wikimedia project. This includes granting and revoking sysop access, and marking users as bots. Their actions are recorded at Meta:Bureaucrat log. Requests for their assistance can be made at m:requests for permissions. Normally, they will not perform actions that can be carried out by a local bureaucrat. Developers The highest degree of technical access (actually a group of levels, the difference between all but the lowest of which isn't really visible to users) is "developer", for those who can make direct changes to the Wikicities software and database. These people, by and large, do not carry out administrative functions, aside from sock puppet checks and reattributing edits. They can be contacted via Wikitech-L. See m:Developer for a list of developers and further information. Administrator abuse Administrators can be removed if they abuse their powers.